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PRE-APPEAL BRIEF REQUEST FOR REVIEW 



Dear Sir: 



Applicants hereby request review of the outstanding rejections, set forth in the Final 
Office Action (hereinafter "FOA") mailed September 18, 2006, in the above-identified 
application. This Request is being filed concurrently with a Notice of Appeal. No 
amendments are being filed with this request. This review is requested for the reasons set 
forth in the Remarks section below. 

REMARKS 

Claims 1-5, 7-1 1, 13-17, 19-21, 23, and 24 are pending in the application. Claims 1- 
5, 7-11, 13-17, 19-21, 23, and 24 stand rejected. 

Claims 1-5, 7-8, 11, 13-21, and 23-24 are rejected under 35 U.S.C. § 103(a) as being 
obvious over Huras (U.S. Patent Publication 2005/0278393) (hereinafter referred to as 
"Huras") in view of Shih et al. (U.S. Patent No. 6,615,223) (hereinafter referred to as 
"Shih"). Applicant respectfully traverses this rejection for the reasons set forth below. 

With respect to claim 1, the cited art fails to teach or suggest "determining that a 
change occurred to data in a first region of a first plurality of regions of a first volume." In 
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the Final Office Action, the Examiner relies upon table spaces 1-4 of FIG. 2 and paragraph 
36 of Huras to teach this feature. FOA, pp. 2-3. 

Paragraph 36 of Huras recites: 

Each log file 107 can contain many log records. Each log record records a 
transaction that interacted with the various tablespaces contained in the 
database. Typically, roll forward 106 can comprise processing selected log 
files in a serial manner, such as starting from one log file (e.g., log file #10) 
and onwards to a succeeding log file (e.g., log file #14) in a discriminatory 
manner as further described below. 

Thus, the log file in Huras records transactions that affect tablespaces in a database, 
not changes that affect data in a particular region of a volume. Databases are clearly not the 
same as volumes, and thus the transactions described in Huras are clearly different than the 
change described in claim 1. 

FIG. 2 of Huras illustrates a data processing system 202, which includes memory 204. 
Database 208, which includes table spaces 1-4, is stored in memory 204. Thus, FIG. 2 
shows that Huras's system is monitoring changes to a database stored in memory, not 
changes to regions of a volume . 

In the Advisory Action mailed November 27, 2006 (hereinafter referred to as "AA"), 
the Examiner further cites paragraphs 21 and 32 of Huras as teaching this feature of claim 1. 
However, these paragraphs merely reiterate that Huras tracks changes to tablespaces in the 
log file and that the log file can be used in database recovery. 

From the portions of Huras cited by FOA and AA, it is clear that Huras tracks 
changes at the database level, not at the volume level. Accordingly, Huras neither teaches 
nor suggests "determining that a change occurred to data in a first region of a first plurality of 
regions of a first volume." 

The cited art also fails to teach or suggest that "the change resulted from a restore 
operation," as recited in claim 1. In the FOA, The Examiner states that paragraphs 20 and 35 
of Huras teach that the change (which the Examiner equates with the transaction that affects 
a tablespace and is recorded in a log file) resulted from a restore operation. FOA, p. 3. 
However, paragraph 20 simply describes how Huras's system can log transactions affecting 
tablespaces and replay those transactions to recover a database (paragraph 20 summarizes 
one of Huras' s claim sets). There is absolutely no indication in the cited portions of Huras 
that the transactions were caused by a restore operation. 
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Paragraph 30 states: "A database management system (see FIG. 2) is used to recover 
the tablespace with minimal errors by restoring a backup version of the tablespace (indicated 
as backup 104), from Monday. The database management system obtains the backup 104 of 
the tablespace and begins a roll forward operation, roll forward 106 of selected log files 107 
to the beginning of Tuesday." Accordingly, the cited portions of Huras teach that a 
tablespace can be recovered by first restoring the tablespace from backup and then applying 
transactions recorded in selected log files to the tablespace. These selected log files store 
transactions that affected the tablespace between the time that the backup version was created 
and the desired restore time. See also Huras, paragraph 69. 

The cited portions of Huras neither teach nor suggest that any changes resulting from 
restoring a tablespace from backup be recorded in the log file (i.e., Huras suggests no need to 
record the changes that occur during the restore operation). Instead, Huras simply notes that 
(1) transactions (which in no way appear to be equivalent to changes that result from a 
restore operation) that affect a tablespace can be recorded in a log file and (2) after a restore 
from backup, the already-created log files can be used to further recover the tablespace. 
Using the already-created log file during a recovery operation is quite clearly not the same as 
determining that a change resulted from the recovery operation. 

The Examiner also appears to equate transactions that occur subsequent to the making 
of a backup with a change resulting from a restore operation, stating: "The changes resulted 
from a restore operation is then taught as a log file representing changes made as a result of a 
transaction executed against the tablespace subsequent to the making of the backup version." 
AA, p. 2 #1. Applicant notes that making a backup is quite clearly not the same as 
performing a restore operation (in fact, the two actions are more properly considered 
opposites; the former involves copying information from the database to backup, while the 
latter applies information from the backup to the database). Furthermore, the transactions 
that occur subsequent to the creation of a backup operation are clearly not part of either the 
backup's creation or the backup's use in a restore operation. Accordingly, such transactions 
are quite clearly not changes resulting from a restore operation. 

In AA, the Examiner further states that "tablespace change history table 215 [of FIG. 
4 of Huras] works with the log file in a way that records modifications of the tablespaces by 
the log records." AA, p. 2 #2. However, tablespace change history table 215 does not record 
changes that result from a restore operation. Instead, as described in paragraphs 46-54 (also 
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cited in AA), the tablespace change history table 215 simply identifies which tablespaces 
were modified by the transactions recorded in a particular log file. For example, tablespace 
change history table 215 indicates that tablespaces 1-4 were modified by transactions #1 and 
#2, which are recorded in log file #10. Huras, FIG. 4, paragraphs 43 and 47. Thus, 
tablespace change history table 215 simply identifies the tablespaces that were modified by 
the transactions recorded in each log file. 

Nothing in paragraphs 46-54 of Huras teaches or suggests that tablespace change 
history table 215 stores changes to a region of a volume that are "caused by a restore 
operation." Instead, these paragraphs simply describe how tablespace change history table 
215 can store information describing the transactions recorded in the log files (paragraphs 
46-51) and be used to recover a tablespace (i.e., the DBMS can recover tablespaces identified 
in the tablespace change history table by replaying the log records 307 within the 
corresponding log file) (paragraphs 52-54). Nothing suggests that tablespace change history 
table 215 is modified during or in response to restoration or recovery (instead, the table is 
used to identify the log files to replay). Accordingly, tablespace change history table 215 and 
its corresponding description do not, and in fact cannot, teach or suggest identifying changes 
that result from a restore operation. 

For the foregoing reasons, the cited portion of Huras does not teach or suggest that 
the "transaction" recorded in the log file (and equated with the "change" of claim 1) resulted 
from a restore operation or that the tablespace change history table identifies changes that 
resulted from a restore operation. Shih, which is correctly not relied upon to teach this 
feature of claim 1, also fails to teach or suggest "the change resulted from a restore 
operation." 

Finally, the cited art fails to teach or suggest "in response to determining that the 
change [which resulted from a restore operation] occurred, updating information identifying 
a set of regions designated for replication to a second volume, wherein subsequent to the 
updating the information, the first region [which was modified by the change] is included in 
the set of regions designated for replication to the second volume," as recited in claim 1. As 
noted above, none of the cited art teaches or suggests that changes resulting from a restore 
operation be identified (e.g., in Huras's log file or tablespace change history table), let alone 
that the region of a volume modified by such a change be designated for replication. 

The Examiner equates the log files in Huras with the information in claim 1 . FOA, p. 

3. However, as noted above, the log files record transactions that can be replayed in order to 
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recover a tablespace, not to replicate a volume. The cited portions of Huras fail to teach or 
suggest using the log files in the act of replicating data from one volume to another. Instead, 
these portions of Huras make no mention of replication at all. 

Thus, while Huras teaches that the log files can be used in recovery, Huras clearly 
does not teach or suggest using the log files in replication. Shih also fails to teach or suggest 
that log files such as those described in Huras would be useful in replication. Both Huras and 
Shih further fail to teach or suggest that a region of a volume that is modified by a change 
caused by a restore operation should be designated for replication. In particular, neither 
reference makes any suggestion that regions of a volume changed by a restore operation 
should be designated for replication. Accordingly, the cited art also fails to teach or suggest 
"updating information identifying a set of regions designated for replication" to designate a 
region changed by a restore operation. 

For at least the foregoing reasons, claim 1 is patentable over the cited art. Claims 3-5, 
7-8, 11,13-21, and 23-24 are patentable over the cited art for similar reasons. 

Claims 9 and 10 are rejected under 35 U.S.C. § 103(a) as being obvious over Huras in 
view of Shih in further view of Lomet (U.S. Pat. 6,578,041). These claims are patentable 
over the cited art for at least the foregoing reasons presented above with respect to claim 1. 

CONCLUSION 

Applicants assert that the application is in condition for allowance and respectfully 
request that a finding withdrawing the final rejection of the claims be issued. 

I hereby certify that this correspondence is being deposited with 
the United States Postal Service as First Class Mail in an envelope 
addressed to: Mail Stop AF, Commissioner for Patents, P. O. Box 
1450, Alexandria, VA 22313-1450, on December 18. 2006 . 

Attorney for Applicant(s) Date'of Signature 



Respectfully submitted, 




Brenna A. Brock 



Attorney for Applicant(s) 
Reg. No. 48,509 
512-439-5087 (Telephone) 
512-439-5099 (Facsimile) 
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